Недавно компания VMware обновила решение Cloud Director Availability 4.7, которое предназначено для создания резервной инфраструктуры в одном из публичных облаков на основе VMware Cloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS). Напомним, что о прошлой версии этого продукта мы писали вот тут.

Новый механизм репликации

До настоящего момента VMware Cloud Director Availability использовал независимые (independent) диски при репликации рабочих нагрузок в облака Cloud Director. Однако это не является их изначальным назначением, что может оказать отрицательное влияние на механику репликации в определенных случаях.

Для уменьшения действия этого фактора и дальнейшего улучшения стабильности и оперативности, а также для обеспечения возможности будущих улучшений, введена система отслеживания репликации Replication Tracking VM (RT VM). Она позволяет использовать новый способ репликации виртуальных машин, совместимый с продуктом Cloud Director Availability 4.7, который зарегистрирован в Cloud Director 10.5+.

Запущенные репликации не будут затронуты этим изменением после обновления VMware Cloud Director Availability. Существует опция для их миграции с независимых дисков на RT VM через пользовательский интерфейс VMware Cloud Director Availability.

Все новые репликации будут использовать этот новый механизм размещения.

Выбор политики хранения

VMware Cloud Director Availability 4.7 получил две новые функции, связанные с выбором политики хранения:

• Выбор политики хранения для каждого диска
• Переназначение политики хранения во время восстановления рабочей нагрузки

Выбор политики для каждого диска

В предыдущих версиях VMware Cloud Director Availability при выборе политики для репликации применялись одни и те же настройки для всех ее дисков. В версии 4.7 вы теперь можете указать политику для каждого диска, сохраняя при этом остальные функции, такие как исключение диска или использование Seed VM.

Эта функция доступна как для облаков Cloud Director, так и для vSphere с одним отличием - для облаков vSphere вы можете выбрать политику хранения и хранилище размещения для каждого диска.

При использовании seed VM репликация будет использовать ее настройки хранилища, и вы не сможете их указать.

Переназначение политики во время восстановления рабочей нагрузки

С учетом оптимизации затрат часто принято использовать медленное, но более дешевое хранилище для данных. Это актуально и для репликаций, где с течением времени может накапливаться большой объем данных.

Однако скорость хранилища может негативно сказаться на производительности рабочей нагрузки при ее переключении в случае сбоя. Чтобы сэкономить клиентам сложный выбор того, где именно пойти на уступки, VMware Cloud Director Availability 4.7 позволяет использовать конкретные настройки хранилища при начальной настройке репликации, а затем выбрать другие настройки при восстановлении реплик.

Эта новая функция доступна как для облаков vSphere, так и для облаков Cloud Director.

Предварительная проверка выполнения планов восстановления

При использовании планов восстановления довольно неприятно достичь определенного этапа их выполнения и обнаружить, что некоторые настройки репликации не настроены, что приводит к неудачному завершению плана. Предварительная проверка выполнения планов восстановления убирает это неудобство и уменьшает время, затрачиваемое на проверку обязательных конфигураций, необходимых Cloud Director Availability для завершения репликации или набора репликаций.

Эти проверки учитывают значительные изменения в инфраструктуре облака, проверяют настройки размещения и наличие недостающих настроек восстановления, а также доступность исходного сайта для случаев миграции.

Эта информация доступна в новой вкладке "Health", которая присутствует в каждом плане восстановления при его выборе. Там вы можете увидеть, когда была проведена последняя проверка, а также доступные действия для устранения обнаруженной проблемы.

В рамках улучшений по обеспечению равенства функций для точек назначения vSphere и Cloud Director, теперь можно выбрать начальную виртуальную машину (Seed VM) при репликации рабочих нагрузок в облака vSphere.

Улучшения для облаков VMware Cloud Director

Появилось несколько новых функций, которые решают проблемы для поставщиков облачных услуг и их клиентов, которые реплицируют рабочие нагрузки в облака назначения Cloud Director:

• Передача меток безопасности NSX, связанных с реплицированной виртуальной машиной при инициировании миграции/восстановления между двумя облаками, работающими на VMware Cloud Director 10.3+.
• Автовыбор политики сайзинга при cloud-to-cloud - если виртуальной машине назначена политика сайзинга на исходном сайте, и на назначенном сайте существует политика с таким же именем, она будет автоматически выбрана при настройке репликации.
• Управление видимостью удаленных облачных сайтов - поставщики облачных услуг могут контролировать, какие партнерские сайты будут видны для каких организаций. Если сайт, на котором активны репликации, скрыт, они будут продолжать отображаться в пользовательском интерфейсе, но невозможно будет создавать новые репликации в/из скрытого сайта.
• Управление политиками для направлений репликации - доступные средства управления расширяются еще одной новой опцией для поддержания возможного направления операций репликации для клиента облака. С ее помощью поставщики облачных услуг могут ограничить клиентов в защите рабочих нагрузок, работающих в облаке, только в направлении их собственного датацентра.

Более подробную информацию о VMware Cloud Director Availability 4.7 можно получить по этой ссылке.

В ноябре компания VMware выпустила обновление продукта Aria Automation November 2023, предназначенного для автоматизации операций виртуальной инфраструктуры VMware vSphere. Ранее мы рассказывали о нововведениях этого решения в плане функций управления в публичных облаках.

В этом выпуске было объявлено о расширении плагин-ориентированного фреймворка для поддержки облачных ресурсов Azure в рамках шаблонов Aria Automation Templates для развертывания вычислительных мощностей, сетей, дисков, storage-аккаунтов и ресурсов баз данных SQL Azure. Использование элементов шаблонов на основе плагинов позволяет клиентам легко получать доступ к ресурсам публичного облака и их свойствам в точном соответствии с определениями вендора.

В этом релизе Aria Automation поддерживает все три крупнейших облачных провайдера: AWS, GCP и Azure. VMware планирует продолжать поддерживать больше типов ресурсов на основе плагинов в будущих ежемесячных релизах.

Еще одной важной функцией является VMware Aria Automation for Secure Hosts, которая теперь предоставляет действия по предварительному и пост-устранению уязвимостей.

Пользователи теперь могут использовать файлы состояний Salt в файловом менеджере, чтобы указать предварительное состояние перед началом исправления уязвимостей. Кроме того, можно установить необязательное пост-состояние для действий после завершения ремедиации. Это улучшение экономит время администраторам ИТ, автоматизируя задачи по предварительной и пост-ремедиации.

Помимо отмеченных выше новых функций, появились следующие улучшения пользовательского опыта в VMware Aria Automation:

1. Дополнительное предупреждение для Day-2 действия Resize

Теперь действие изменения размера дополнено предупреждением о том, что если функция Hot Add не включена в vCenter, машина будет перезагружена и не будет работать в это время. Когда горячее добавление включено, пользователи могут выбрать, перезагружать ли машину или нет при изменении, причем "не перезагружать" установлено по умолчанию.

2. Поддержка онпремизного SCM (GitLab Enterprise) в VMware Aria Automation SaaS

Эта функция позволяет администраторам настроить GitLab Enterprise как эндпоинт для репозитория. Шаблоны VMware Aria Automation, скрипты Terraform и сервисы ABX могут быть импортированы из GitLab Enterprise. Это расширение сервиса VMware Aria Automation SaaS клиенты могут использовать как в локальных, так и в SaaS-средах.

3. Поддержка свойств OVF в vCenter Content Library

Теперь поддерживается указание свойств для пакетов OVF/OVA, хранящихся в библиотеке содержимого vCenter, в шаблонах VMware Aria Automation с использованием свойства 'ovfProperties:', доступного в элементе vSphere Machine. Шаблоны OVF/OVA, созданные в кластере vSphere или хранящиеся в библиотеке содержимого vCenter, отображаются в сопоставлениях образов в VMware Aria Automation Assembler.

4. Улучшения плагина Infoblox IPAM

Версия 1.5.1 плагина VMware Infoblox для VMware Aria Automation вносит несколько улучшений, таких как повышение удобства использования, устранение false positives и повышение безопасности за счет использования OpenSSL 3.0.x, Photon 4.x и Python 3.10.11 в качестве среды выполнения ABX. Подробнее об этом тут.

Более подробно о новых возможностях VMware Aria Automation November 2023 вы можете узнать из Release Notes.

На днях мы рассказали о рекомендациях при апгрейдах и накатывании обновлений в среде VMware vSphere, которые проводятся с помощью решения VMware Lifecycle Manager. Также мы писали о новых возможностях облачной версии этого продукта - VMware Cloud Provider Lifecycle Manager 1.6.

Недавно компания VMware выпустила интересное видео, рассказывающее о новой функциональности этой платформы:

Ролик будет полезен всем облачным администраторам, которые следят за новостями о главном средстве обновления компонентов виртуальной инфраструктуры VMware vSphere.

Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...

С будущим крупным выпуском vSphere компания VMware планирует ввести режим строгой безопасности для vCenter (strong security mode), отражающий позицию безопасности VMware, который будет рекомендован к применению партнерам и клиентам в их операциях по управлению виртуальной инфраструктурой.

В строгом режиме не поддерживается SHA-1 как функция криптографического хеширования. VMware рекомендует заменить ее более безопасным и поддерживаемым SHA-256. Строгий режим также поддерживает полные SSL-сертификаты в качестве механизма обмена доверием, что может повлиять на некоторые API vSphere, использующие certificate thumbprints в качестве аргументов или как часть ответа API. Такие API могут не поддерживаться при включенном строгом режиме.

Параллельно со строгим режимом будет поддерживаться совместимый режим безопасности (compatible security mode) в целях обратной совместимости. Совместимый режим все еще поддерживает SHA-1 в качестве функции криптографического хеширования и опирается на certificate thumbprints для SSL-сертификатов как на действительный источник доверия. Использование совместимого режима не будет рекомендовано. Переключение между режимами будет происходить через свойство виртуального модуля vCenter Server Appliance. Подробная информация будет предоставлена в документации следующего выпуска vSphere.

Как будут выглядеть апгрейды существующих инфраструктур?

Начиная с грядущего крупного выпуска, все новые развертывания экземпляров vCenter будут настроены с включенным по умолчанию режимом строгой безопасности. При этом будут затронуты все решения партнеров, зависящие от устаревших алгоритмов криптографического хеширования, таких как SHA-1 или MD5. Клиенты смогут переключиться на compatible-режим, но он будет считаться устаревшим и не рекомендоваться VMware.

Обновленные до следующей версии экземпляры vCenter, ранее функционировавшие в уже существующих развертываниях, будут продолжать работать в режиме совместимости, установленном по умолчанию, если клиент не переключился на строгий режим до обновления vCenter. Таким образом, VMware рассчитывает, что клиенты будут применять самые строгие настройки безопасности, доступные в настоящее время. Это изменение повлияет и на плагины vSphere Client, использующие SHA-1 при регистрации в менеджере расширений vSphere. Отказ от адаптации к требованиям режима строгой безопасности vCenter повлечет за собой риск того, что соответствующий плагин vSphere Client станет непригодным для использования.

Влияние на плагины vSphere Client

Переход с SHA-1 на SHA-256

Все партнеры VMware должны иметь в виду, что начиная с предстоящего крупного выпуска, плагины vSphere Client, использующие устаревший стандарт SHA-1, не будут поддерживаться, когда в инфраструктуре клиента включен режим строгой безопасности vSphere. Чтобы решить эту проблему и обеспечить совместимость своих решений, VMware настоятельно советует партнерам убедиться, что версии плагинов vSphere Client, которые они предлагают сейчас, поддерживают SHA-256 в качестве алгоритма шифрования.

Алгоритм SHA-1 находится в состоянии устаревания с момента выпуска vSphere 7.0 Update 1. VMware дала возможность для плагинов vSphere Client регистрироваться в менеджере расширений с использованием SHA-256 в качестве алгоритма хеширования с выпуском vSphere 7.0 Update 3. Как следующий шаг в этом процессе, для предстоящего крупного выпуска vSphere, плагинам необходимо отказаться от использования SHA-1 в качестве функции криптографического хеширования.

Переход от certificate thumbprints к полным SSL-сертификатам

Вместе с миграцией с SHA-1, функции расширений клиента vSphere постепенно переходят к использованию полных SSL-сертификатов для регистрации плагинов. Полная поддержка сертификатов была введена для Client SDK с выпуском vSphere 8.0 Update 2. Выполнение полной проверки SSL-сертификата во время SSL handshake более безопасно, чем проверка отпечатка SSL-сертификата, даже если плагин уже использует отпечаток SSL-сертификата SHA-256.

Чтобы обеспечить совместимость плагинов в обе стороны сейчас партнерам рекомендуется предоставлять свои решения с возможностью регистрации у менеджера расширений клиента vSphere, используя как сертификат, так и отпечаток. Это необходимо, потому что в некоторых средах могут быть экземпляры vCenter, которые не поддерживают сертификаты, и которые могут попытаться загрузить новую версию плагина, зарегистрированную только с сертификатом.

Например, они могут применить certificate thumbprint (используя SHA-256 в качестве алгоритма хеширования) для регистрации с vCenter, работающим на версии 8.0 U1 или ранее, и полный SSL-сертификат для vCenter 8.0 U2 или более поздней версии.

Локальные плагины уходят в прошлое

Плагины vSphere Client, основанные на устаревшей локальной архитектуре плагинов вскоре уже не будут поддерживаться. Локальные плагины были объявлены устаревшими с момента выпуска vSphere 8.0 GA, и их поддержка прекращается со следующим крупным релизом vSphere.

Всем партнерам VMware необходимо предоставить своим клиентам версию плагина, основанную на удаленной архитектуре плагинов, чтобы они могли продолжить использование партнерского решения в следующем релизе vSphere.

Переход на TLS 1.3

Начиная с предстоящего обновления vSphere, VMware будет поддерживать протокол безопасности транспортного уровня TLS версии 1.3 вместе с устаревшим TLS 1.2, который включен по умолчанию. В следующем крупном выпуске TLS 1.2 и TLS 1.3 будут сосуществовать, и конфигурация vCenter по умолчанию будет поддерживать обе версии протокола. Однако в следующем релизе vSphere будет введен настраиваемый режим vCenter, поддерживающий только TLS 1.3.

VMware настоятельно рекомендует партнерам подумать о добавлении поддержки TLS 1.3 в их плагины, чтобы эти решения нормально работали во всех конфигурациях vCenter.

Администраторы виртуальной инфраструктуры VMware vSphere время от времени сталкиваются с проблемой завершения зависших виртуальных машин. Если в клиенте vSphere Client сделать этого не удаются, приходится заходить в сервисную консоль ESXi или в командную строку PowerCLI/PowerShell и проводить там операции по завершению процесса этой ВМ. Сегодня мы расскажем о 5 способах, которыми это можно сделать.

1. С использованием PowerCLI

Stop-VM - это командлет, используемый для завершения работы виртуальной машины. На самом деле он используется для выключения ВМ, но добавление параметра kill приведет к завершению соответствующих процессов ВМ на ESXi, фактически уничтожая ее. Делается это так:

Stop-VM -kill <отображаемое имя ВМ> -Confirm:$false

2. С использованием esxcli

Esxcli - это интерфейс командной строки (CLI), который предоставляет доступ к ряду пространств имен, таких как vm, vsan, network и software, позволяя выполнять задачи, изменять настройки и так далее. Таким образом, если вам нужно завершить работу неотвечающей виртуальной машины с использованием esxcli, можно действовать следующим образом:

• Получить список виртуальных машин, размещенных на ESXi:

esxcli vm process list

Красным выделен идентификатор World ID виртуальной машины.

• Скопируйте значение World ID и выполните команду:

esxcli vm process kill --type=soft -w=796791

Команда не выдает никакой обратной связи, кроме случаев, когда она не сможет найти виртуальную машину или вы укажете неверный параметр.

Параметр type принимает три значения:

• Soft – позволяет процессу VMX завершиться корректно, аналогично команде kill -SIGTERM
• Hard – немедленно завершает процесс VMX, аналогично команде kill -9 или kill -SIGKILL
• Force – останавливает процесс VMX, когда не работают варианты Soft или Hard

3. С использованием утилиты vim-cmd

Vim-cmd - это еще одна утилита командной строки, очень похожая на esxcli, но с несколько иным синтаксисом. Также она может использоваться для управления ВМ и другими ресурсами. Соответственно, вот как используется vim-cmd для завершения работы ВМ:

1. Выведите все ВМ на текущем подключенном хосте ESXi и запишите vmid (первый столбец) неотвечающей ВМ:

vim-cmd vmsvc/getallvms

2. Получите состояние питания ВМ, используя ее vmid. Этот шаг необязателен, так как вы уже знаете, что с ВМ что-то не так:

vim-cmd vmsvc/power.getstate 36

3. Сначала попробуйте вариант power.shutdown:

vim-cmd vmsvc/power.shutdown 36

4. Если по какой-то причине ВМ не удается выключить, попробуйте использовать вместо этого power.off:

vim-cmd vmsvc/power.off 36

Следующий скриншот демонстрирует пример использования указанных выше команд для завершения работы ВМ.

4. С использованием esxtop

Esxtop - это отличная утилита, которая предоставляет информацию о том, как ESXi использует системные ресурсы. Она может использоваться для устранения неполадок, сбора статистики производительности и многого другого.

Вот как это делается:

Нажмите Shift+v, чтобы изменить представление на виртуальные машины:

Нажмите <f>, чтобы отобразить список полей, затем нажмите <c>. Это добавит столбец с идентификатором Leader World ID (LWID) в представление. Нажмите любую клавишу, чтобы вернуться в главное меню.

• Найдите зависшую виртуальную машину в столбце Name и запишите ее LWID.
• Нажмите k и введите значение LWID в строке запроса World to kill (WID). Нажмите Enter:

Чтобы быть полностью уверенным, подождите 30 секунд перед тем, как проверить, что виртуальная машина больше не отображается в списке. Если она все еще там, попробуйте снова. В случае неудачи, скорее всего, вам придется перезагрузить хост ESXi.

5. С помощью традиционной команды kill

Это самый грубый метод завершения работы виртуальной машины. Но он документирован на сайте VMware, хотя и немного по-другому. Виртуальная машина представляет собой серию процессов, выполняемых на ESXi. Используя команду ps ниже, можно вывести процессы, связанные, например, с виртуальной машиной под названием Web Server.

ps | grep "Web Server"

Если вы внимательно посмотрите, вы увидите, что значение во втором столбце одинаково для всех процессов. Это значение идентификатора VMX Cartel, которое, хотя и отличается от значения World ID, все же может быть использовано для завершения работы виртуальной машины следующим образом:

kill 797300

Если процессы продолжают работать, попробуйте kill -9 <идентификатор процесса>:

kill -9 797300

Не так давно мы подробно рассказывали об инициативе Private AI компании VMware, которая позволит создать надежную инфраструктуру для корпоративных систем искусственного интеллекта. Сегодня мы расскажем о новых инициативах VMware и Intel в этой сфере.

Поскольку AI обеспечивает огромный рост производительности и позволяет создавать новые возможности, многие основные функции в типичном бизнесе будут трансформироваться, включая продажи, маркетинг, разработку программного обеспечения, операции с клиентами и обработку документов. Компания McKinsey прогнозирует, что влияние генеративного AI на производительность может добавить около $4.4 триллиона ежегодно к мировой экономике.

Но в основе этого остается конфиденциальность данных предприятий. Поэтому в августе 2023 года на мероприятии VMware Explore в Лас-Вегасе VMware объявила о запуске VMware Private AI и VMware Private AI Foundation с NVIDIA. Ну а на конференции Explore Europe было объявлено о дальнейшем расширении экосистемы VMware Private AI с двумя ключевыми партнерами.

VMware Private AI с Intel дает возможность использования AI для всех организаций

VMware и Intel сотрудничают более 20 лет для обеспечения возможностей следующего поколения - от центров обработки данных до облаков с самым широким портфолио надежных корпоративных решений, позволяющих компаниям двигаться быстрее, внедрять больше инноваций и работать эффективнее.

VMware и Intel помогут предприятиям создавать и развёртывать частные и безопасные модели AI, работающие на основе архитектуры VMware Cloud Foundation, и повысить производительность AI, используя программный пакет Intel AI software suite, процессоры Intel Xeon Scalable четвёртого поколения со встроенными ускорителями и графическими процессорами Intel Max Series.

Давайте рассмотрим, какую ценность предприятия могут ожидать от этого партнёрства.

• Обеспечение конфиденциальности и безопасности для моделей AI: архитектурный подход VMware Private AI для AI-сервисов обеспечивает конфиденциальность и контроль корпоративных данных, а также интегрированную безопасность и управление. Это партнёрство поможет предприятиям создать и развернуть частные и безопасные модели AI с интегрированными возможностями безопасности в VCF и его компонентах.
• Повышение производительности AI: достижение высокой производительности моделей AI и LLM с использованием интегрированных возможностей, встроенных в VCF, процессоры Intel, аппаратные ускорители и оптимизированное программное обеспечение. Например, vSphere, один из основных компонентов VCF, включает планировщик Distributed Resources Scheduler (DRS), который улучшает управление рабочими нагрузками AI, группируя хосты в кластеры ресурсов для разных приложений и обеспечивая доступ ВМ к необходимому количеству вычислительных ресурсов, предотвращая узкие места на уровне ресурсов и оптимизируя их использование.
• Повсеместный доступ к AI: VMware и Intel предоставляют предприятиям полностью проверенный стек ИИ на уже развёрнутых кластерах. Этот стек позволяет предприятиям проводить подготовку данных, машинное обучение, тонкую настройку и оптимизацию вывода, используя процессоры Intel, аппаратные ускорители, программный пакет Intel для AI и VCF в вашей локальной среде.

VMware Private AI на базе Intel поддерживает как генеративный AI, так и классические случаи использования AI/ML. Он использует мощность VMware Cloud Foundation и программного пакета Intel для AI, процессоров и аппаратных ускорителей. Эта архитектурная экосистема объединяет VMware, Intel, поставщиков ML Ops (cnvrg.io, Domino Data Labs, DKube, Kubeflow и т.д.), крупных производителей серверов OEM (таких как Dell Technologies, Hewlett Packard Enterprise и Lenovo), и глобальных системных интеграторов, таких как HCL, Kyndryl и Wipro.

Варианты использования

VMware Private AI и сотрудничество с Intel позволяют предприятиям использовать несколько сценариев, безопасно внедряя классические модели AI/ML и большие языковые модели, тонкую настройку и развертывание их в частной корпоративной среде. Вот описание основных случаев использования.

• Генерация кода: предприятия могут использовать свои модели без риска потери интеллектуальной собственности или данных и ускорить работу разработчиков, включив генерацию кода.
• Опыт решения проблем в контактных центрах: предприятия могут настраивать модели на основе своей внутренней документации и статей базы знаний, включая конфиденциальные данные поддержки, и, в свою очередь, обеспечить более эффективное обслуживание клиентов и поддержку с существенным сокращением человеческого взаимодействия в инцидентах поддержки/обслуживания.
• Классическое машинное обучение: классические модели ML используются для различных реальных приложений в таких отраслях, как финансовые услуги, здравоохранение и Life Sciences, розничная торговля, исследования и производство. Популярные случаи использования ML включают персонализированный маркетинг, визуальный контроль качества в производстве, персонализированную медицину и прогнозирование спроса в розничной торговле.
• Рекомендательные движки: предприятия могут улучшить взаимодействие с потребителями, предлагая или рекомендуя дополнительные продукты. Это может основываться на различных критериях, включая предыдущие покупки, историю поиска, демографическую информацию и другие факторы.

VMware Private AI с IBM обеспечивает доступ к WatsonX в локальных средах

IBM и VMware работают над VMware Private AI, чтобы позволить предприятиям получить доступ к платформе IBM WatsonX в частных, локальных средах и гибридном облаке для безопасного обучения и тонкой настройки своих моделей с помощью платформы WatsonX. Стратегическое партнерство между IBM и VMware направлено на то, чтобы обеспечить клиентам возможность легко перейти на гибридное облако и модернизировать их критически важные рабочие нагрузки. Теперь, имея возможность выбора времени, места и способа интеграции технологий GenAI с VMware Cloud Foundation, предприятия смогут быстро обучать и развертывать индивидуальные возможности AI в рамках всего предприятия, сохраняя при этом полный контроль и соответствие требованиям к их данным. Благодаря этому партнерству в области AI между VMware и IBM, предприятия получают мощное решение, использующее лучшие инновации от локальных решений VMware в едином стеке, чтобы обеспечить унифицированную среду, интегрированную с данными и возможностями AI, предоставляемыми технологией партнера IBM Cloud.

• Получите частные и безопасные модели с VMware Private AI: конфиденциальность и безопасность имеют первостепенное значение для предприятий. Теперь предприятия могут создавать свои частные и безопасные модели AI с VMware Private AI с IBM, используя несколько интегрированных возможностей конфиденциальности, безопасности и микросегментации в VCF.
• Развертывание моделей AI/ML в локальной среде и в облаке: это партнерство позволяет предприятиям обучать, проверять, настраивать и развертывать частные и безопасные модели AI/ML как в локальной среде, так и в облаке IBM Cloud.
• Выбор между открытыми или проприетарными моделями IBM: это партнерство позволяет предприятиям выбирать большие языковые модели (LLM), предоставляя доступ к открытым моделям от Hugging Face, выбранным IBM, моделям сторонних производителей и серии обученных IBM фундаментальных моделей.

Вот несколько примеров поддерживаемых моделей, доступных на watsonx.ai:

• Открытые модели: Llama 2 (70b)
• Модели сторонних производителей: StarCoder (15.5b)
• Проприетарные модели IBM: Granite (13b)

Архитектура решения

Эта полноценная архитектура, построенная на основе VMware Cloud Foundation, использует Red Hat OpenShift и сочетает в себе возможности платформы IBM WatsonX для Gen AI и классических AI/ML-нагрузок с Enterprise-уровнем безопасности. С помощью этой архитектуры предприятия могут использовать watsonx.ai для доступа к открытым моделям IBM, выбранным из Hugging Face, а также к другим моделям сторонних производителей и серии обученных IBM фундаментальных моделей для поддержки вариантов использования GenAI и для обучения, проверки, настройки и развертывания классических моделей AI/ML.

Варианты использования

VMware Private AI с IBM может обеспечить несколько сценариев использования для предприятий, безопасно активируя настройку больших языковых моделей, тонкую настройку и развертывание их в частной корпоративной среде. В области генерации кода акцент сделан на ускорении продуктивности разработчиков с учетом критически важных вопросов конфиденциальности и интеллектуальной собственности. Кроме того, VMware Private AI в сотрудничестве с IBM представляет значительную возможность улучшить взаимодействие в контактных центрах. Это партнерство обещает улучшение качества контента и обратной связи для клиентов, что приводит к более точным ответам и, в целом, улучшению клиентского опыта. Это партнерство может значительно упростить ИТ-операции, автоматизировав задачи, такие как управление инцидентами, отчетность, управление тикетами и мониторинг, в конечном итоге экономя время и усилия агентов ИТ-операций. Наконец, продвинутые возможности поиска информации, возникшие благодаря этому сотрудничеству, могут повысить продуктивность сотрудников, оптимизируя поиск документов и исследование политик, способствуя более продуктивной рабочей среде.

IBM Consulting предоставляет клиентам экспертизу в решениях, специфичных для VMware и генеративного AI

Ранее в этом году IBM Consulting создала Центр компетенции по генеративному AI и теперь имеет более 1000 консультантов со специализированными знаниями в области генеративного AI, которые работают с глобальными клиентами, чтобы повысить производительность в ИТ-операциях и основных бизнес-процессах, таких как кадровые или маркетинговые, улучшить клиентский опыт и создать новые бизнес-модели.

Это, в сочетании с экспертизой IBM, специфичной для VMware, и сервисными возможностями, поможет ускорить бизнес-трансформации клиентов с использованием корпоративного AI на архитектуре VMware Private AI.

Кроме того, для клиентов, желающих модернизировать и трансформировать свои рабочие нагрузки, IBM Consulting планирует интегрировать услуги IBM WatsonX и VMware Private AI в свой проприетарный IBM Consulting Cloud Accelerator, чтобы помочь ускорить процесс трансформации инфраструктур в облака. После релиза эта интеграция поможет с процессами reverse engineering и генерацией кода, а также с управлением операциями Day-2 и последующими для бесперебойного предоставления услуг управления гибридным облаком от IBM Consulting.

Полезные ссылки

• VMware Private AI
• VMware with Intel Press Release
• VMware with IBM Press Release
• IBM launch blog
• Технический блог о VMware Private AI
• Блог HPE

На прошедшей недавно конференции Explore 2023 Europe компании VMware и Intel рассказали о своем видении того, как в будущем будет происходить управление и контроль над уязвимостями ниже уровня ОС.

Благодаря расширенному партнерству VMware и Intel, данные телеметрии от процессоров Intel Core позволят решению Workspace ONE Unified Endpoint Management (UEM) собирать данные об уязвимостях ниже уровня операционной системы. Эта новая интеграция сочетает в себе данные на уровне чипа с автоматическим устранением проблем и возможностями отчетности Workspace ONE UEM для повышения безопасности конечных устройств.

Видео старое, но суть объясняет:

Фундаментальные уязвимости

Обеспечение безопасности современных работников является постоянной задачей, так как киберугрозы увеличиваются как в частоте, так и в сложности. На конференции VMware Explore 2023 в Лас-Вегасе команда VMware рассказала о важности принятия комплексного подхода к управлению уязвимостями и его влиянии на безопасность организации. Новая эффективная платформа управления уязвимостями предлагает не только широкий охват платформ ОС, но и глубокое понимание от уровня приложений и ОС до firmware и оборудования. Уязвимости ниже уровня ОС, или фундаментальные уязвимости, особенно опасны, поскольку они остаются незамеченными традиционными сканерами уязвимостей и могут привести к потенциально катастрофическим последствиям.

Управление уязвимостями VMware и Intel

Было анонсировано решение для создания и сбора данных о фундаментальных уязвимостях для компьютеров с Windows с процессорами Intel Core (с технологией Intel vPro или без нее). Благодаря глубокому анализу и знанию различных производителей ПК, Intel обладает уникальной способностью интерпретировать данные конфигурации с конечных устройств и обнаруживать те уязвимости, которые не находятся традиционными сканерами безопасности. Данные сопоставляются с известными фундаментальными уязвимостями и упаковываются в анализы рисков с соответствующим контекстом и деталями для идентификации и последующего устранения.

Этот улучшенный телеметрический подход на самом низком уровне поможет дополнить движок управления уязвимостями и комплаенсом для решения Workspace ONE. Этот продукт будет визуализировать данные активных событий, позволяя клиентам имплементировать более сильную стратегию безопасности конечных устройств, использующую управление уязвимостями как выше, так и ниже уровня ОС. Новые данные об оборудовании не только дадут клиентам большую видимость их парка устройств, но и соберут более богатый контекст для повышения эффективности оценки уязвимостей и их устранения.

Бета-версия Intel Chip to Cloud

Облачная служба Intel Device Health скоро будет доступна в портале программы раннего доступа VMware Anywhere Workspace Early Access.

Если вы уже являетесь участником программы раннего доступа, вы можете выбрать бета-версию Intel Chip to Cloud в своем пользовательском профиле, когда она станет доступной. Бета-программа будет включать возможности анализа уязвимостей вместе с интеграцией Intel vPro Chip to Cloud. Если вы еще не являетесь участником, вы можете зарегистрироваться здесь.

Также рекомендуем посмотреть сессию по управлению уязвимостями "Решение загадки риска: управление уязвимостями, воздействием и устранением [EUSB1597BCN]".

Еще в 2015 году мы писали о том, что проект VMware Sample Exchange вышел в бета-версии. Это портал, предназначенный для разработчиков средств автоматизации виртуальной инфраструктуры, где они могут скачивать примеры кода на разных языках и для разных платформ под множество компонентов виртуальной среды.

За прошедшие 8 лет этот проект накопил огромное количество различных сценариев и примеров кода как от сотрудников VMware, так и от сообщества разработчиков, которые постоянно добавляют туда новые сэмплы (вы тоже можете это делать).

Если при первоначальном запуске портала там было всего 250 сэмплов, то теперь их стало более двух тысяч, как видно на скиншоте ниже:

Посмотрите, какое огромное количество языков и платформ представлено на портале, одних только дэшбордов для решения vRealize (Aria) Operations - 300 штук!

Примерно столько же представлено и сценариев для автоматизации инфраструктуры средствами PowerShell/PowerCLI, а вот это уже - большая находка.

Недавно мы писали о сайзинге пропускной способности канала для растянутых кластеров VMware vSAN Stretched Clusters, а сегодня поговорим о том, какие технологии и архитектуры поддерживаются для функций Datastore Sharing в данном типе кластеров. Давайте посмотрим на поддержку Datastore Sharing в рамках разных сценариев, для которых работают архитектуры HCI Mesh и vSAN Max.

О поддержке данных возможностей для растянутых кластеров рассказал Дункан Эппинг. В своей заметке он ссылается на раздел vSAN Max and Disaggregated storage страницы часто задаваемых вопросов по vSAN.

Есть несколько потенциальных комбинаций растянутого кластера и перечисленных возможностей, на момент релиза VMware vSAN 8.0 Update 2 поддержка возможностей выглядит следующим образом:

• Датастор vSAN Stretched Cluster, расшаренный с vSAN Stretched Cluster –> Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с vSAN Cluster (не stretched) –>Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (не stretched) –>Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, symmetric) –>Поддерживается
• Датастор vSAN Stretched Cluster, расшаренный с Compute Only Cluster (stretched, asymmetric) –> Не поддерживается

В чем разница между симметричным и асимметричным растянутым кластером? На следующем изображении, взятом из конфигурации vSAN Stretched Cluster, это лучше всего объяснено:

Если вы используете растянутый кластер vSAN и растянутый Compute Only, то обычно используется Asymmetric-конфигурация, поэтому шаринг датасторов в этом случае не поддерживается.

Сегодня мы расскажем о том, как определить пропускную способность сети между площадками при использовании кластеров vSAN HCI и кластеров vSAN Max в конфигурации Stretched Cluster.

В растянутом кластере два домена отказоустойчивости данных содержат один или несколько хостов, а третий домен отказоустойчивости содержит виртуальный модуль Witness для определения доступности сайтов данных. Далее каждый домен отказоустойчивости данных мы будем называть сайтом. Конфигурации растянутого кластера vSAN могут распространяться на разные расстояния, при условии что соблюдаются требования по пропускной способности (bandwidth) и задержке (latency).

Минимально поддерживаемая пропускная способность и latency между сайтами

Пропускная способность, которая требуется между сайтами, в большой степени зависит от объема операций ввода-вывода (I/O), который генерируют рабочие нагрузки, но будут влиять и другие факторы, такие как используемая архитектура (vSAN ESA или OSA), размер кластера и сценарии обработки сбоев. Ниже указаны минимально поддерживаемые значения, но рассчитанные оценки для конкретной инфраструктуры могут привести к требованиям по пропускной способности, превышающим указанные минимумы.

Также вы можете использовать vSAN Sizer в сочетании с руководством по проектированию vSAN, чтобы создать оптимальную конфигурацию для вашего растянутого кластера.

Требования к пропускной способности между сайтами

Приведенные ниже формулы помогут оценить необходимую пропускную способность сети между сайтами. Предполагается, что два сайта данных географически расположены достаточно близко друг к другу, чтобы соответствовать требованиям по задержке.

Понимание активности I/O, соотношения чтения и записи и размеров I/O

Рабочие нагрузки состоят из нескольких характеристик. Не только количество активности I/O значительно различается от нагрузки к нагрузке, но чтения и записи часто происходят с разными скоростями и разными размерами I/O. С целью предоставления простой формулы для расчета мы будем использовать следующие переменные для расчета оценочной пропускной способности связи между сайтами для растянутого кластера (ISL):

• Скорость I/O всех команд чтения и записи, измеряемая в IOPS
• Соотношение чтения/записи (например, 70/30)
• Средний размер I/O, измеряемый в KB

Пропускная способность - это измерение на основе скорости, что означает, как много данных передается за определенный период времени. В отличие от измерения неактивных данных, где оно принимает форму байтов, килобайтов и т. д., измерение данных в процессе передачи по сети выражается в битах (b), килобитах (Kb), мегабитах (Mb) или гигабитах (Gb), и период времени - "в секунду" (ps). Обсуждая скорости, мы должны помнить о конвертации байтов в биты.

Давайте используем простой пример, где общий профиль I/O требует 100 000 I/O в секунду (IOPS), в среднем 8 KB каждый, где 70% IOPS - это чтение, и 30% - запись, в растянутой конфигурации. В этом сценарии запись I/O (30 000 IOPS в среднем 8 KB каждый) будет равна 240 000 Kbps или 240 Mbps. Это будет оценкой пропускной способности ISL, необходимой для этого профиля.

Простейший, но потенциально менее точный способ оценки требований к пропускной способности - это просто использовать входные данные, представляющие общие потребности кластера. Если кто-то использует формулу для расчета отдельных рабочих нагрузок в кластере, сумма этих расчетов предоставит результирующие требования к пропускной способности. Возможно, вы захотите выделить гораздо больше минимального рассчитанного количества, так как рабочие нагрузки со временем неизбежно становятся более ресурсоемкими.

Формулы для расчета оценок пропускной способности указаны ниже, они привязаны к используемой архитектуре: vSAN OSA или vSAN ESA. С введением архитектуры vSAN Express Storage (ESA) появляются все новые возможности по обеспечению производительности хранилища на совершенно новом уровне. Поэтому при использовании ESA рекомендуется тщательно отслеживать использование ISL, чтобы убедиться, что есть достаточная пропускная способность, необходимая для того, чтобы рабочие нагрузки не были ограничены со стороны ISL. Для дополнительной информации см. статью: "Использование vSAN ESA в топологии растянутого кластера".

Формулы расчета пропускной способности для vSAN ESA

Трафик репликации от I/O гостевой ВМ - это доминирующий тип трафика, который мы должны учесть при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). У растянутых кластеров vSAN ESA трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ. Требуемая пропускная способность между двумя сайтами данных (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr) * коэффициент сжатия (CR).

Расчет пропускной способности для ISL, обслуживающего растянутый кластер vSAN с использованием ESA, отличается от формулы, используемой для OSA. vSAN ESA сжимает данные до их репликации между сайтами. В результате ESA уменьшает использование пропускной способности ISL, эффективно увеличивая его возможности для передачи большего количества данных.

Чтобы учесть это в расчете в топологии, использующей ESA, формула учитывает оценочное соотношение сжатия сохраненных данных. Давайте рассмотрим следующий пример, где мы оцениваем экономию в 2 раза благодаря использованию сжатия в vSAN ESA. Мы используем простое значение "2x" (также называемое 2:1 или 50%) для простоты. Фактические коэффициенты сжатия будут зависеть от данных, хранящихся в вашей среде. Пример 2:1 - это не предположение о том, что вы на самом деле можете увидеть в своей среде.

1. Преобразуйте это в процент от исходного размера, разделив конечный размер на начальный размер. Это даст, например, результат ".50".
2. Умножьте окончательное рассчитанное значение из описанной в этой статье формулы на ".50".
   В результате формула будет выглядеть так:

B = Wb * md * CR * mr * CR

Как отмечалось выше, коэффициенты сжатия часто могут быть представлены разными способами, чтобы выразить экономию места.

Например:

• Сжатие, выраженное в соотношении. [начальный размер]:[конечный размер]. Соотношение сжатия 2:1 указывает на то, что данные будут сжаты до половины своего исходного размера.
• Сжатие, выраженное в виде множителя экономии. Соотношение сжатия 2x указывает на то, что данные будут сжаты до половины своего исходного размера. Это то, что отображается в представлении ёмкости кластера vSAN.
• Сжатие, выраженное в процентах от исходного размера. Значение сжатия 50% (или, .50) указывает на то, что данные будут сжаты до половины своего исходного размера.

Примеры между сайтами (для vSAN ESA)

• Рабочая нагрузка 1

С примером рабочей нагрузки в 10 000 записей в секунду на рабочую нагрузку vSAN со средним размером записи 8 KB потребуется 80 МБ/с или 640 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.

B = 640 Мбит/с * 1.4 * 1.25 * .50 = 560 Мбит/с.

Учитывая требования к сети vSAN, требуемая пропускная способность составляет 560 Мбит/с.

• Рабочая нагрузка 2

В другом примере, 30 000 записей в секунду, 8KB записи, потребуется 240 MB/s или 1 920 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.

B = 1,920 Мбит/с * 1.4 * 1.25 * .50 = 1,680 Мбит/с или примерно 1,7 Гбит/с.

Требуемая пропускная способность составляет примерно 1,7 Гбит/с.

Рабочие нагрузки редко состоят только из чтений или записей, и обычно включают общее соотношение чтения к записи для каждого варианта использования. Используя общую ситуацию, когда общий профиль I/O требует 100 000 IOPS, из которых 70% являются записью, а 30% чтением, в растянутой конфигурации, IO записи - это то, на что рассчитана пропускная способность межсайтовой связи. С растянутыми кластерами vSAN, трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ.

Формулы расчета пропускной способности для vSAN OSA

Как и в растянутых кластерах с использованием ESA, трафик репликации от I/O гостевой ВМ в растянутом кластере с использованием OSA является доминирующим типом трафика, который мы должны учитывать при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). В растянутых кластерах vSAN OSA трафик чтения по умолчанию обслуживается сайтом, на котором размещена ВМ. Требуемая пропускная способность между двумя данными сайтами (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr), или:

B = Wb * md * mr

Множитель данных состоит из накладных расходов на трафик метаданных vSAN и различных связанных операций. VMware рекомендует использовать множитель данных 1.4. Множитель ресинхронизации включен для учета событий ресинхронизации. Рекомендуется выделять пропускную способность по верхней границе требуемой пропускной способности для событий ресинхронизации. Для учета трафика ресинхронизации рекомендуются дополнительные 25%.

Планируйте использование vSAN ESA для всех новых кластеров vSAN. Эта архитектура быстрее и эффективнее, чем vSAN OSA, и, зачастую, уменьшает количество хостов, необходимых для того же объема рабочих нагрузок. Формула для vSAN OSA остается актуальной для тех, у кого уже есть установки vSAN OSA.

Требования к пропускной способности между Witness и сайтом данных

В топологии растянутого кластера хост-машина Witness просто хранит компоненты, состоящие из небольшого объема метаданных, которые помогают определить доступность объектов, хранящихся на сайтах с данными. В результате сетевой трафик, отправляемый на сайт для этой машины, довольно мал по сравнению с трафиком между двумя сайтами с данными через ISL.

Одной из наиболее важных переменных является объем данных, хранящихся на каждом сайте. vSAN хранит данные в виде объектов и компонентов. Она определяет, сколько компонентов нужно для данного объекта, и где они должны быть размещены по всему кластеру, чтобы поддерживать устойчивость данных в соответствии с назначенной политикой хранения.

Архитектура vSAN ESA обычно использует больше компонентов, чем OSA. Это следует учитывать при расчете потенциально необходимой пропускной способности для машины Witness.

Обязательно выберите правильный размер хоста vSAN Witness. При развертывании предлагается четыре размера машины (Tiny, Medium, Large и Extra Large), каждый из которых предназначен для размещения разных размеров сред. Посмотрите статью "Deploying a vSAN Witness Appliance" для получения дополнительной информации.

Формулы расчета пропускной способности Witness для vSAN ESA и OSA

Сетевое взаимодействие сайтов с Witnessn состоит исключительно из метаданных, что делает запросы к сетевым ресурсам Witness гораздо более легковесными, что отражается в поддерживаемых минимальных требованиях к пропускной способности и задержке.

Поскольку формула для оценки необходимой пропускной способности Witness основана на количестве компонентов, ее можно использовать для расчета растянутых кластеров, использующих OSA или ESA. Поскольку ESA обычно использует больше компонентов на объект (возможно, в 2-3 раза больше) по сравнению с OSA, следует учитывать большее количество компонентов на ВМ при использовании архитектуры на базе ESA.

Базовая формула

Требуемая пропускная способность между Witness и каждым сайтом равна ~1138 Б x Количество компонентов / 5с

1138 Б x Кол-во компонентов / 5 секунд

Значение 1138 Б происходит от операций, которые выполняются, когда предпочтительный сайт выходит из строя, и второстепенный сайт берет на себя владение всеми компонентами. Когда основной сайт выходит из строя, второстепенный сайт становится лидером. Witness отправляет обновления новому лидеру, после чего новый лидер отвечает Witness, по мере обновления владения. Требование в 1138 Б для каждого компонента происходит из сочетания полезной нагрузки от Witness к резервному агенту, за которым следуют метаданные, указывающие, что предпочтительный сайт не работает. В случае отказа предпочтительного сайта, связь должна быть достаточно хорошей, чтобы позволить изменение владения кластером, а также владение всеми компонентами в течение 5 секунд.

Примеры пропускной способности Witness к сайту (OSA)

• Нагрузка 1

Если ВМ состоит из:

• 3 объектов
• Параметр допустимого числа отказов (FTT=1)

Приблизительно 166 ВМ с этой конфигурацией потребовало бы, чтобы Witness содержал 996 компонентов (166 ВМ * 3 компонента/ВМ * 2 (FTT+1) * 1 (Ширина полосы)). Чтобы успешно удовлетворить требования пропускной способности Witness для общего числа 1 000 компонентов на vSAN, можно использовать следующий расчет:

Преобразование байтов (Б) в биты (б), умножьте на 8:

В = 1138 Б * 8 * 1 000 / 5с = 1 820 800 бит в секунду = 1.82 Мбит/с

VMware рекомендует добавить безопасный запас в 10% и округлить вверх.

B + 10% = 1.82 Мбит/с + 182 Кбит/с = 2.00 Мбит/с

Таким образом, с учетом безопасного запаса в 10%, можно утверждать, что для каждых 1 000 компонентов подходит канал 2 Мбит/с.

• Нагрузка 2

Если ВМ состоит из:

• 3 объектов
• FTT=1
• Stripe с параметром 2

Приблизительно 1 500 ВМ с этой конфигурацией потребовало бы хранения 18 000 компонентов на Witness. Чтобы успешно удовлетворить требования пропускной способности Witness для 18 000 компонентов на vSAN расчет будет таким:

B = 1138 Б * 8 * 18 000 / 5с = 32 774 400 бит в секунду = 32.78 Мбит/с
B + 10% = 32.78 Мбит/с + 3.28 Мбит/с = 36.05 Мбит/с

Используя общее уравнение 2 Мбит/с на каждые 1 000 компонентов, (NumComp/1000) X 2 Мбит/с, можно увидеть, что 18 000 компонентов действительно требует 36 Мбит/с.

Пропускная способность Witness для конфигураций с 2 узлами (OSA)

• Пример удаленного сайта 1

Рассмотрим пример 25 ВМ в конфигурации с 2 узлами, каждая с виртуальным диском 1 ТБ, защищенные при FTT=1 и Stripe Width=1. Каждый vmdk будет состоять из 8 компонентов (vmdk и реплика) и 2 компонентов для пространства имен ВМ и swap-файла. Общее количество компонентов составляет 300 (12/ВМx25ВМ). С 300 компонентами, используя правило (300/1000 x 2 Мбит/с), требуется пропускная способность 600 кбит/с.

• Пример удаленного сайта 2

Рассмотрим другой пример 100 ВМ на каждом хосте, с таким же ВМ выше, с виртуальным диском 1 ТБ, FTT=1 и SW=1. Общее количество компонентов составляет 2 400. Используя правило (2 400/1000 x 2 Мбит/с), требуется пропускная способность 4.8 Мбит/с.

Вот так и рассчитывается пропускная способность для разных рабочих нагрузок и конфигураций в среде vSAN. Понимание этих метрик и формул поможет в проектировании и развертывании решений vSAN, которые обеспечивают оптимальную производительность и надежность.

На конференции Explore 2023 сотрудники VMware подробно рассказали о следующем этапе развития управления Android-устройствами - Android Management API (AMAPI). Недавно бета-версия AMAPI стала доступна для пользователей. Она поддерживает управление Android-устройствами, зарегистрированными в режиме рабочего профиля, который используется для рабочих или личных устройств.

AMAPI - это новый подход к управлению Android-устройствами уровня предприятия. AMAPI является частью Android — он встроен в ОС и разработан Google. Это открывает возможности, которые недоступны в текущем подходе к управлению платформой Android Enterprise, который называется Custom Device Policy Controller (DPC). Примером функции, доступной только в AMAPI, является недавно введенный режим потерянного устройства (Corporate Owned Personally Enabled, COPE). Вот три основных преимущества AMAPI:

• Простота: Workspace ONE Unified Endpoint Management (UEM) создает желаемое состояние устройства и передает его AMAPI, который применяет его. Это упрощает процесс поддержки новых функций Android в консоли Workspace ONE UEM.
• Нативность: AMAPI является частью Android и обновляется и поддерживается Google. Следовательно, лучшие практики управления устройствами встроены в AMAPI компанией Google, и это общий стек, используемый в экосистеме Android.
• Возможности: AMAPI имеет дополнительные средства, чтобы гарантировать, что политики применяются к устройствам. Например, AMAPI может обеспечивать минимальные требования к сложности пароля на личных устройствах.

В чем разница между AMAPI и Custom DPC?

Сегодня Workspace ONE UEM использует подход к Android Enterprise, называемый Custom DPC. С Custom DPC решение Workspace ONE UEM распределяет политики, внутренние приложения и многое другое на Workspace ONE Intelligent Hub, который действует как основное управляющее приложение устройства или рабочего профиля. Intelligent Hub применяет эти ресурсы к устройству и возвращает информацию об устройстве в Workspace ONE UEM.

Публичные приложения — это приложения, опубликованные в управляемом Google Play Store. Для распространения и доставки публичных приложений на устройства Workspace ONE UEM использует Google Play EMM API.

Теперь давайте рассмотрим AMAPI. С AMAPI решение Workspace ONE UEM передает желаемое состояние устройства в AMAPI. Аналогично Custom DPC это определяет, какие публичные приложения AMAPI должен установить на устройство. Workspace ONE также передает, какие управляющие политики — требования к паролям, сертификаты, настройки разрешений для приложений — AMAPI должен применить. В свою очередь, AMAPI передает политики клиенту Android Device Policy (ADP), который применяет их к устройству. В AMAPI именно ADP, встроенный компонент Android, выступает в качестве основного управляющего приложения на устройстве. ADP работает на всех Android-устройствах с GMS на Android 5.1+. Обратите внимание, что Workspace ONE UEM сам определяет минимальные поддерживаемые версии ОС.

Помимо применения управляющих политик, ADP также передает информацию о состоянии устройства в AMAPI, который, в свою очередь, передает эту информацию в Workspace ONE UEM через Google Pub/Sub.

Workspace ONE Intelligent Hub остается ключевым компонентом для управления устройствами. Он обрабатывает распространение сертификатов и внутренних приложений и позволяет использовать уникальные функции, такие как предоставление продуктов и Freestyle Orchestrator. Intelligent Hub также является не только управляющим клиентом. Он предоставляет унифицированный каталог приложений VMware, пакет Mobile Threat Defense SDK, интеграцию с Intelligence для продвинутой аналитики и многое другое. Именно поэтому Intelligent Hub присутствует на всех устройствах, которыми управляются с помощью AMAPI.

AMAPI вносит несколько изменений в опыт работы администратора и конечного пользователя устройства.

В качестве администратора вы увидите два основных обновления в консоли Workspace ONE UEM:

1. При создании профилей Android теперь вы будете выбирать, создавать ли профили для Custom DPC или для AMAPI.
2. Теперь вы можете выбрать, будут ли новые устройства, регистрирующиеся в Workspace ONE UEM, управляться с использованием Custom DPC или AMAPI. Это может быть установлено по режиму (Рабочий профиль, COPE или полностью управляемый) и по организационной группе.

В качестве конечного пользователя устройства:

1. Помимо начала регистрации через Intelligent Hub, теперь вы можете начать регистрацию своих личных устройств, запустив URL регистрации AMAPI. Этот URL регистрации предоставляется администратором UEM и может распространяться через QR-код, текст, электронную почту, внутренний сайт или другими способами.
2. Когда вы устанавливаете политику, требующую взаимодействия конечного пользователя, AMAPI предпримет действия, чтобы удостовериться, что требования политики соблюдаются. Например, когда вы устанавливаете минимальные требования к паролю устройства через профили, AMAPI приостановит управляемые приложения до тех пор, пока пароль устройства не соответствует требованиям политики. AMAPI также направляет конечного пользователя на установку пароля, соответствующего политике.

AMAPI представляет будущее управления устройствами Android и добавляет много преимуществ, включая уникальные функции. VMware рекомендует организациям ознакомиться с AMAPI и применять его в соответствии с их требованиями.

Управляется ли устройство с помощью Custom DPC или AMAPI, изначально нужно будет решить в момент регистрации устройства. Организации смогут внедрить подход "ограничить и развивать" при использовании AMAPI. Не воздействуя на зарегистрированные устройства, управляемые с помощью Custom DPC, организации могут настроить Workspace ONE UEM для использования AMAPI для регистрации новых устройств. Организации могут включить AMAPI для новых регистраций для отдельных режимов управления (рабочий профиль, COPE или полностью управляемый), а также только для конкретных организационных групп.

В будущем будет предусмотрена поддержка миграции устройств с Custom DPC на AMAPI без необходимости повторной регистрации. Такая миграция будет поддерживаться для всех режимов — рабочего профиля, COPE и полностью управляемого.

Бета-версия AMAPI доступна уже сегодня. На текущий момент она поддерживает управление устройствами в режиме рабочего профиля, который используется для управления личными устройствами пользователей (BYOD). По мере развития бета-версии будет добавлена поддержка режима COPE и, позднее, режима полного управления. Для получения дополнительной информации о различных режимах управления Android Enterprise вы можете посмотреть документ "Operational Tutorial for Managing Android Devices".

Аналогично, поддержка режима рабочего профиля в AMAPI будет доступна в производственных средах в первую очередь, затем последует COPE и, в конце концов, режимы полного управления.

Зарегистрироваться на бета-тестирование AMAPI можно на портале программы раннего доступа VMware Anywhere Workspace Early Access. Руководства по тестированию и другие ресурсы для AMAPI можно найти в проекте Android Intelligent Hub.

Компания VMware объявила о доступности обновленной версии решения Cloud Provider Lifecycle Manager 1.6 (VCPLCM). Напомним, что этот продукт предназначен для автоматизации рутинных операций жизненного цикла продуктов, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях. О версии VCPLCM 1.4 мы писали вот тут.

В предыдущей версии (VCPLCM 1.5) VMware добавила автоматическую регистрацию Usage Meter и Interop Reporting, а также улучшения в выполнении задач. В этом релизе представлено несколько нововведений с основным акцентом на:

• Улучшении пользовательского опыта
• Расширении поддержки продуктов и обслуживания

Давайте кратко рассмотрим, что это такое.

Улучшенный пользовательский опыт

Новая версия предоставляет больше управляющих элементов для пользователя. Появилась новая опция "Administration", которая помогает провайдерам безопасно делегировать и контролировать операции по обслуживанию и управлению соответствующим пользователям, каждый из которых входит под своими учетными данными.

Еще одним большим изменением является внедрение нового пользовательского интерфейса для регистрации продукта, что делает процесс развертывания новых продуктов в VCPLCM проще и быстрее.

Расширенная поддержка продуктов

Теперь пользователи могут регистрировать NSX Advanced Load Balancer в VCPLCM и интегрировать его с VMware Cloud Director и Usage Meter.

Пользователи теперь могут создавать резервные копии данных и обеспечивать эффективное восстановление виртуального модуля VCPLCM, минимизируя потерю данных в случае системных сбоев или серьезных ошибок.

Также появился переключатель «режим обслуживания» для компонентов продукта. Это важное нововведение, поскольку часто при обновлении продукты нужно перезапустить или остановить по разным причинам, например, при накатывании патча на узле. В этих ситуациях узел будет недоступен без уведомления оператора. Этот переключатель будет отмечать узлы как "в режиме обслуживания", чтобы пользователи знали статус продукта / компонента.

Теперь давайте рассмотрим эти функции подробнее:

1. Улучшенный пользовательский опыт

Существенно был улучшен пользовательский интерфейс и значительно упрощены операции, такие как развертывание и регистрация существующего продукта.

Также была добавлена опция, позволяющая пользователям просматривать существующие бинарные файлы в репозитории через пользовательский интерфейс и соответствующим образом развертывать/обновлять продукты.

Теперь нет необходимости заходить через ssh на устройство, чтобы проверить бинарные файлы.

2. Управление доступом на основе ролей

В версии 1.6 был введен доступ на основе ролей, и теперь пользователи могут выполнять следующие действия:

• Конфигурация внешних источников аутентификации (LDAP/AD)
• Определение и назначение ролей с разрешениями для различных операций
• Вход в систему разными пользователями и выполнение задач, назначенных запрашивающим пользователям.

Управление пользователями:

Управление ролями и разрешениями:

3. Операции "Day-2": режим обслуживания для VMware Cloud Director

Теперь пользователи могут включать/выключать режим обслуживания для ячеек VCD.

Это полезно при выполнении любых операций с патчами или технического обслуживания ячеек VCD и для обеспечения бесперебойной работы. С этим усовершенствованным пользовательским интерфейсом можно определить состояние каждой ячейки VCD непосредственно через портал VCPLCM.

4. Резервное копирование и восстановление VCPLCM

Это долгожданная функция, так как VMware получила много запросов касательно функции резервного копирования и восстановления виртуального модуля VCPLCM.

Теперь пользователи могут создавать резервные копии и восстанавливать устройства VCPLCM той же версии, причем файл резервной копии защищен паролем, который пользователи должны задать при создании резервной копии.

Ниже перечислены компоненты, которые можно восстановить с использованием файла резервной копии:

• Развернутые/зарегистрированные продукты
• Зарегистрированные компоненты инфраструктуры
• Последние задачи и журналы
• Источники аутентификации, роли и пользователи
• Содержимое хранилища (закрытые данные, такие как пароли и ключи)
• Сертификаты и ключи для устройства VCP LCM

Однако бинарные файлы продукта внутри папки /cplemrepo виртуального модуля не будут резервно копироваться, и их придется резервно копировать вручную.

Вот так выглядит защита паролем:

Вот так восстановление:

5. Регистрация NSXALB с VCD и Usage Meter

Теперь вы можете регистрировать NSX ALB как компонент инфраструктуры и интегрировать его с VMware Cloud Director и Usage Meter. Эта интеграция может быть выполнена при развертывании VMware Cloud Director и Usage Meter.

6. Улучшения API

• REST API VCPLCM обновлен до версии 4
• Версии 1, 2 и 3 API по-прежнему доступны, но рекомендуется использовать версию 4
• Дополнительные операции API для перезапуска, возобновления работы и отката задач.
• Дополнительная операция API для получения полезной нагрузки запроса задачи, создания отчета о совместимости и архивации/чтения уведомлений
• CLI и GUI используют v4. Однако CLI также имеет возможность работать со старыми версиями API (необходимо указать их явно)
• Обновленная коллекция Postman с соответствующими образцами полезной нагрузки для обеих версий API доступна здесь.

Полный список нововведений VMware Cloud Provider Lifecycle Manager 1.6 приведен в Release Notes.

На прошедшей в этом году конференции Explore 2023 компания VMware сделала множество интересных анонсов в сфере искусственного интеллекта (AI). Сейчас, когда технологии генеративного AI выходят на первый план, особенно важно организовать инфраструктуру для них - то есть подготовить программное и аппаратное обеспечение таким образом, чтобы расходовать ресурсы, необходимые для AI и ML, наиболее эффективно, так как уже сейчас в сфере Corporate AI требуются совершенно другие мощности, чтобы обслуживать эти задачи.

Продолжаем рассказывать об анонсах главного события в сфере виртуализации VMware Explore 2023. Мы уже писали о двух главных анонсах в сфере контейнеризованных приложений:

• Tanzu Application Platform 1.6 - средства для интеграции существующих и новых приложений в бэкенд инфраструктуру контейнеров с соблюдений требований комплаенса и безопасности.
• Tanzu Application Engine -  уровень абстракции, ориентированный на приложения, который позволяет им работать с постоянным операционным управлением и соответствием стандартам — как внутри облаков, так и между ними.

Ну а сегодня мы расскажем о службах Tanzu Intelligence Services, которые были образованы в результате перепаковки некоторых сервисов VMware Aria и добавления новых служб (в частности VMware Tanzu with Intelligent Assist).

Управление приложениями в облаках представляет собой сложную совокупность данных и технологий. Распределенные изолированные инструменты и данные затрудняют получение видимости зависимостей между приложениями, инфраструктурой и услугами. Централизация управления этими разнородными системами и обеспечение доступа к общим данным помогает устранить изолированные хранилища данных. Это позволяет командам быстрее реагировать на проблемы и настраивать приложения и среды на основе глубоких и практичных аналитических данных.

Новые службы Tanzu Intelligence Services включают часть портфолио VMware Aria с общей платформой данных, чтобы усилить функции инженеров платформ и улучшить операции в облаке. Tanzu Intelligence Services активно оптимизирует стоимость, производительность и безопасность приложений в облаках, интегрируя возможности машинного обучения и искусственного интеллекта.

На конференции VMware представила следующие нововведения и улучшения:

• VMware Tanzu with Intelligent Assist (пока в статусе технологического превью) улучшит операции, сделав их более проактивными, и значительно оптимизирует рабочие процессы за счет использования чат-бота с генеративным AI на базе LLM, который использует федеративную архитектуру данных в интегрированных решениях VMware Tanzu Hub.

• VMware Tanzu CloudHealth (пока в бета-версии, бывший продукт Aria Cost) предоставляет дополнительные возможности для экономии средств за счет прогнозирования с использованием машинного обучения для улучшения планирования бюджета и динамической корректировки размеров кластеров Kubernetes без простоя.

• VMware Tanzu Insights (бывший продукт Aria Hub) позволяет операционным командам лучше устранять проблемы благодаря целостной видимости и глубоким аналитическим данным на основе ML/AI в распределенных средах Kubernetes, Amazon Web Services (AWS) и Microsoft Azure. Первый релиз этого продукта планируется на третий квартал финансового года 2024.

• VMware Tanzu Guardrails (бывший продукт Aria Guardrails) улучшает управление в многооблачных средах за счет новой автоматизации на основе политик для создания зон на AWS и Azure, а также введения автоматизированного принудительного выполнения политик.

• VMware Tanzu Transformer (бывший продукт Aria Migration) увеличивает вероятность успешной миграции и модернизации приложений за счет поддержки оценки и планирования миграции в облака VMware и публичные облака с рабочими процессами планирования. API для интеграции со сторонними системами пока поставляется в бета-версии.

Сервисы Tanzu, пришедшие из линейки Aria, продолжат предоставлять решения для управления облаками с семействами продуктов Aria Automation и Aria Operations для сред на базе VMware Cloud. Сейчас Aria Universal Suite доступен как самостоятельный продукт, так и в составе изданий VMware Cloud.

Недавно компания VMware выпустила обновленную версию платформы виртуализации vSphere 8 Update 2, где было сделано много интересных изменений. В частности, несколько поменялся интерфейс механизма vSphere Cluster Services (vCLS).

Напомним, что VMware High Availability (HA) и DRS при активации создают системные виртуальные машины vCLS в vSphere. Это обязательно, так как эти ВМ развертываются на каждом кластере vSphere после обновления vCenter Server до версии v7.0 Update 2 или более поздней. Теперь интерфейс vSphere Cluster Services изменился с выпуском vSphere 8.0 U2, про который Дункан Эппинг рассказывает в своем видео:

Начиная с vSphere 7.0 Update 2, автоматически создается и применяется новое правило anti-affinity. Это правило гарантирует, что каждые 3 минуты проводится проверка, не расположены ли несколько ВМ vCLS на одном и том же хранилище данных. Если это так, правило инициирует операцию storage vMotion и перераспределяет эти ВМ по разным хранилищам.

Когда хранилище данных, на котором расположены ВМ vCLS, переводится в режим обслуживания, вам нужно вручную применить Storage vMotion к машинам vCLS, чтобы переместить их в новое место, или перевести кластер в режим Retreat Mode.

Режим Retreat Mode позволяет отключить службу vSphere Clustering Service для автоматического удаления виртуальных машин-агентов. Это полезно, когда вам нужно выполнить задачи по техническому обслуживанию инфраструктуры, в частности хранилищ, чтобы эти вспомогательные ВМ вам не мешали.

Ранее Retreat Mode был доступен только через расширенную конфигурацию, а теперь его можно включать через пользовательский интерфейс, начиная с vSphere 8.0 U2. Для этого откройте vSphere Client, выберите ваш кластер > Configure > General (в разделе vSphere Cluster Service), далее нажмите Edit vCLS mode:

В прошлых статьях мы рассказывали об архитектуре платформы виртуализации vStack и ее технических возможностях, а также о ее требованиях к оборудованию. Сегодня мы поговорим о процедуре установки этого решения. Установка ПО vStack проста и состоит из нескольких последовательных шагов...

Продолжаем рассказывать об интересных анонсах главного события года в мире виртуализации - конференции VMware Explore 2023. Сегодня организации стремятся использовать AI, но беспокоятся о рисках для интеллектуальной собственности, утечке данных и контроле доступа к моделям искусственного интеллекта. Эти проблемы определяют необходимость корпоративного приватного AI. О новой инициативе VMware Private AI мы детально рассказывали вот тут, а сегодня поговорим о референсной открытой архитектуре Private AI Reference Architecture for Open Source.

Архитектура VMware Private AI Reference для Open Source интегрирует инновационные технологии OSS (open source software) для предоставления открытой эталонной архитектуры создания и использования OSS-моделей на базе VMware Cloud Foundation. На конференции Explore 2023 компания VMware анонсировала сотрудничество с ведущими компаниями, которые создают ценность корпоративного AI в ИТ-инфраструктуре больших организаций на базе Open Source:

• Anyscale: VMware внедряет широко используемую открытую вычислительную платформу Ray в средах VMware Cloud. Решение Ray on VMware Cloud Foundation облегчает масштабирование AI и рабочих нагрузок Python для инженеров по данным и MLOps, позволяя использовать собственные вычислительные ресурсы для ML-нагрузок, а не переходить в публичное облако.

• Domino Data Lab: VMware, Domino Data Lab и NVIDIA объединились для предоставления унифицированной платформы для аналитики, Data Science и инфраструктуры, оптимизированной, проверенной и поддерживаемой для развертывания AI/ML в финансовой отрасли.

• Глобальные системные интеграторы: VMware сотрудничает с ведущими интеграторами систем, такими как Wipro и HCL, чтобы помочь клиентам ощутить преимущества Private AI, создавая и предоставляя готовые решения, которые объединяют VMware Cloud с решениями экосистемы партнеров по AI.

• Hugging Face: VMware сотрудничает с Hugging Face для обеспечения работы SafeCoder на виртуальных платформах, о чем было объявлено на VMware Explore. SafeCoder – это коммерческое решение-помощник по написанию кода для предприятий, включая услуги, программное обеспечение и поддержку. VMware использует SafeCoder внутри для своих процессов и публикует эталонную архитектуру с примерами кода для обеспечения максимально быстрого времени достижения ценности для клиентов при развертывании и эксплуатации SafeCoder на инфраструктуре VMware.

• Intel: VMware vSphere/vSAN 8 и Tanzu оптимизированы под программный набор интеллектуальных технологий Intel для использования новых встроенных ускорителей AI на последних процессорах Intel Xeon Scalable четвертого поколения.

Кроме того, VMware объявляет о запуске новой программы VMware AI Ready (пока это доступно только для частных решений, например, в партнерстве с NVIDIA), которая предоставит ISV (независимым производителям программного обеспечения) инструменты и ресурсы, необходимые для валидации и сертификации своих продуктов на архитектуре VMware Private AI Reference. Программа будет доступна ISV, специализирующимся на ML и LLM Ops, инженерии данных, инструментах для разработчиков AI, а также встроенных AI-приложениях. Ожидается, что новая программа станет активной к концу 2023 года.

Если вы откроете VMware vSphere Client и посмотрите на список виртуальных дисков, прикрепленных к виртуальному модулю (Virtual Appliance) сервера vCenter, то вы увидите там аж 17 виртуальных дисков VMDK. Многие администраторы удивляются - а не многовато ли это?

Для VMware vSphere 7 список дисков и их назначение указаны в статье базы знаний KB 78515 (их там 16), ну а ниже мы расскажем о семнадцати VMDK для VMware vSphere 8:

Много? Много!

Компания VMware опубликовала интересное техническое видео с обзором всех новых возможностей средства создания отказоустойчивых хранилищ vSAN 8 Update 2, работающих на базе обновленной платформы виртуализации vSphere 8 Update 2.

Видео длится 25 минут и покрывает все технические аспекты новых функций платформы, включая новую архитектуру vSAN Max, о которой рассказывается во всех подробностях.

Напомним также, что ранее VMware опубликовала еще одно полезное видео о новых возможностях vSphere 8 Update 2:

Ну и, конечно, нельзя не напомнить об этой ссылке на хранилище технических статей и документов о платформе VMware vSAN.

Продолжаем рассказывать об интересных анонсах главного события года в мире виртуализации - конференции VMware Explore 2023. Сегодня организации стремятся использовать AI, но беспокоятся о рисках для интеллектуальной собственности, утечке данных и контроле доступа к моделям искусственного интеллекта. Эти проблемы определяют необходимость корпоративного приватного AI.

Об этом недавно компания VMware записала интересное видео:

Рассмотрим этот важный анонс немного детальнее. Вот что приватный AI может предложить по сравнению с публичной инфраструктурой ChatGPT:

• Распределенность: вычислительная мощность и модели AI будут находиться рядом с данными. Это требует инфраструктуры, поддерживающей централизованное управление.
• Конфиденциальность данных: данные организации остаются в ее владении и не используются для тренировки других моделей без согласия компании.
• Контроль доступа: установлены механизмы доступа и аудита для соблюдения политик компании и регуляторных правил.

Приватный AI не обязательно требует частных облаков, главное — соблюдение требований конфиденциальности и контроля.

Подход VMware Private AI

VMware специализируется на управлении рабочими нагрузками различной природы и имеет огромный опыт, полезный для имплементации успешного приватного AI. К основным преимуществам подхода VMware Private AI относятся:

• Выбор: организации могут легко сменить коммерческие AI-сервисы или использовать открытые модели, адаптируясь к бизнес-требованиям.
• Конфиденциальность: современные методы защиты обеспечивают конфиденциальность данных на всех этапах их обработки.
• Производительность: показатели AI-задач равны или даже превышают аналоги на чистом железе, как показали отраслевые тесты.
• Управление: единый подход к управлению снижает затраты и риски ошибок.
• Time-to-value: AI-окружения можно быстро поднимать и выключать за считанные секунды, что повышает гибкость и скорость реакции на возникающие задачи.
• Эффективность: быстрое развертывание корпоративных AI-сред и оптимизация использования ресурсов снижают общие затраты на инфраструктуру и решение задач, которые связаны с AI.

Таким образом, платформа VMware Private AI предлагает гибкий и эффективный способ внедрения корпоративного приватного AI.

VMware Private AI Foundation в партнерстве с NVIDIA

VMware сотрудничает с NVIDIA для создания универсальной платформы VMware Private AI Foundation with NVIDIA. Эта платформа поможет предприятиям настраивать большие языковые модели, создавать более безопасные модели для внутреннего использования, предлагать генеративный AI как сервис и безопасно масштабировать задачи генерации результатов. Решение основано на средах VMware Cloud Foundation и NVIDIA AI Enterprise и будет предлагать следующие преимущества:

• Масштабирование уровня датацентров: множественные пути ввода-вывода для GPU позволяют масштабировать AI-загрузки на до 16 виртуальных GPU в одной виртуальной машине.
• Производительное хранение: архитектура VMware vSAN Express обеспечивает оптимизированное хранение на базе хранилищ NVMe и технологии GPUDirect storage over RDMA, а также поддерживает прямую передачу данных от хранилища к GPU без участия CPU.
• Образы виртуальных машин vSphere для Deep Learning: быстрое прототипирование с предустановленными фреймворками и библиотеками.

В решении будет использоваться NVIDIA NeMo, cloud-native фреймворк в составе NVIDIA AI Enterprise, который упрощает и ускоряет принятие генеративного ИИ.

Архитектура VMware для приватного AI

AI-лаборатории VMware совместно с партнерами разработали решение для AI-сервисов, обеспечивающее приватность данных, гибкость выбора ИИ-решений и интегрированную безопасность. Архитектура предлагает:

• Использование лучших моделей и инструментов, адаптированных к бизнес-потребностям.
• Быстрое внедрение благодаря документированной архитектуре и коду.
• Интеграцию с популярными открытыми проектами, такими как ray.io, Kubeflow, PyTorch, pgvector и моделями Hugging Face.

Архитектура поддерживает коммерческие и открытые MLOps-инструменты от партнеров VMware, такие как MLOps toolkit for Kubernetes, а также различные надстройки (например, Anyscale, cnvrg.io, Domino Data Lab, NVIDIA, One Convergence, Run:ai и Weights & Biases). В состав платформы уже включен самый популярный инструмент PyTorch для генеративного AI.

Сотрудничество с AnyScale расширяет применение Ray AI для онпремизных вариантов использования. Интеграция с Hugging Face обеспечивает простоту и скорость внедрения открытых моделей.

Решение Private AI уже применяется в собственных датацентрах VMware, показывая впечатляющие результаты по стоимости, масштабу и производительности разработчиков.

Чтобы начать использование VMware Private AI можно начать с прочтения референсной архитектуры и примеров кода. Также очень полезной вам может оказаться вот эта статья от VMware.

Недавно опубликованный компанией VMware технический документ "Troubleshooting TCP Unidirectional Data Transfer Throughput" описывает, как устранить проблемы с пропускной способностью однонаправленной (Unidirectional) передачи данных по протоколу TCP. Решение этих проблем, возникающих на хосте vSphere/ESXi, может привести к улучшению производительности. Документ предназначен для разработчиков, опытных администраторов и специалистов технической поддержки.

Передача данных по протоколу TCP очень распространена в средах vSphere. Примеры включают в себя трафик хранения между хостом VMware ESXi и хранилищем данных NFS или iSCSI, а также различные формы трафика vMotion между хранилищами данных vSphere.

В компании VMware обратили внимание на то, что даже крайне редкие проблемы с TCP могут оказывать несоразмерно большое влияние на общую пропускную способность передачи данных. Например, в некоторых экспериментах с чтением NFS из хранилища данных NFS на ESXi, кажущаяся незначительной потеря пакетов (packet loss) в 0,02% привела к неожиданному снижению пропускной способности чтения NFS на 35%.

В документе описывается методология для выявления общих проблем с TCP, которые часто являются причиной низкой пропускной способности передачи данных. Для этого производится захват сетевого трафика передачи данных в файл трассировки пакетов для офлайн-анализа. Эта трассировка пакетов анализируется на предмет сигнатур общих проблем с TCP, которые могут оказать значительное влияние на пропускную способность передачи данных.

Рассматриваемые проблемы с TCP включают в себя потерю пакетов и их переотправку (retransmission), длительные паузы из-за таймеров TCP, а также проблемы с Bandwidth Delay Product (BDP). Для проведения анализа используется решение Wireshark и описывается профиль для упрощения рабочего процесса анализа. VMware описывает системный подход к выявлению общих проблем с протоколом TCP, оказывающих значительное влияние на пропускную способность канала передачи данных - поэтому инженерам, занимающимся устранением проблем с производительностью сети, рекомендуется включить эту методологию в стандартную часть своих рутинных проверок.

В документе рассмотрены рабочие процессы для устранения проблем, справочные таблицы и шаги, которые помогут вам в этом нелегком деле. Также в документе есть пример создания профиля Wireshark с предустановленными фильтрами отображения и графиками ввода-вывода, чтобы упростить администраторам процедуру анализа.

Скачать whitepaper "Troubleshooting TCP Unidirectional Data Transfer Throughput" можно по этой ссылке.

На сайте проекта VMware Labs вышло небольшое обновление утилиты Power Actions версии 1.0.3. Напомним, что о прошлой версии мы писали вот тут. Это средство представляет собой плагин для клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI пользователями, не имеющими опыта работы с PowerShell. Утилита также реализует библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации.

Давайте посмотрим, что нового в VMware Power Actions 1.0.3:

• Исправление для https://flings.vmware.com/power-actions/bugs/1517 (проверка общего имени в сертификате TLS)
• Исправление для https://flings.vmware.com/power-actions/bugs/1513 (перезапуск Virtual Appliance)
• Добавлены настройки прокси-сервера, которые позволяют развертывание в средах с прокси (https://flings.vmware.com/power-actions/bugs/149
• Разрешение специальных символов, например, "&" в полях для паролей
• Исправлены настройки DNS в случае статического IP адреса

Загрузить виртуальный модуль VMware Power Actions 1.0.3 можно по этой ссылке.

Интересное видео о том, как это работает:

Многие клиенты VMware используют кластерные приложения, такие как Microsoft WSFS и Oracle RAC, на платформе vSphere. Эти кластерные системы требуют, чтобы диски были общими для всех серверных узлов внутри приложения. Одним из требований к механизму блокировки дисковых ресурсов является использование SCSI3-Persistent Reservations или режим multi-writer.

Пользователи VMware vSphere обычно применяли физический pRDM для кластерных приложений. С выпуском vSphere 6.7 SCSI3-PR были добавлены к vVols, и это вызвало большой интерес со стороны администраторов. RDM не так просты просты в эксплуатации, они требуют ручного выделения и назначения индивидуальных LUN для всех узлов кластера приложения. Это создает большую операционную нагрузку. Также в этом случае ограничены некоторые возможности виртуализации при использовании томов RDM и требуется взаимодействие с администратором хранилища для изменения его размера. Кроме того, вам также следует помечать свои RDM флагом "Perennially Reserved" для сокращения времени загрузки и повторного сканирования хранилищ.

Внедрению технологии vVols мешало отсутствие одной конкретной функции — возможности увеличивать размер общих дисков, когда кластерное приложение работает.

С выпуском VMware vSphere 8.0 Update 2 было устранено последнее преимущество RDM перед vVols. Теперь вы можете увеличивать размер общих дисков (физическое совместное использование шины physical bus sharing или же multi-writer) без необходимости останавливать кластер приложения. Для WSFC первоначально поддерживается SCSI, но для Oracle RAC поддерживаются и SCSI, и NVMeoF (FC, TCP).

Это означает, что клиентам больше не нужно выполнять все ручные операции по выделению RDM LUN для кластерных приложений. Они могут использовать vVols и выделять приложение и ВСЕ диски на стандартном хранилище данных vVols. Это позволяет клиентам значительно упростить развертывание кластерных приложений и снизить сложность их среды. Это также упрощает ежедневные операции администратора хранилища, поскольку администратор виртуальной инфраструктуры теперь может создавать и изменять размер общих дисков прямо из vCenter! Другим преимуществом является то, что vVols не являются традиционными LUN, и время повторного сканирования хранилищ и время загрузки хоста не зависят от количества выделенных vVols, в отличие от RDM, если только они не помечены флагом Perennially Reserved.

Чтобы показать вам, насколько проста операция изменения размера, VMware сделала короткое демо, показывающее процесс увеличения общего диска в активном кластере Microsoft WSFC (кликните на картинку для открытия GIF в новом окне):

В рамках прошедшей недавно конференции Explore 2023 компания VMware сделала немало интересных анонсов продуктов и технологий, которые появятся в ближайшем будущем. Одной из главных новостей стало объявление о скором выпуске второго пакета обновлений флагманской платформы виртуализации VMware vSphere 8 Update 2. Сегодня мы рассмотрим ту ее часть, которая касается аппаратного обеспечения, а особенно нагрузок, использующих модули GPU для задач искусственного интеллекта, графических приложений...

Очередной рассказ об анонсах новых продуктов и технологий, которые были сделаны на проходящей сейчас конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации. Вчера мы писали о новом решении Tanzu Application Engine, которое предназначено для введения уровня абстракции, ориентированного на приложения, чтобы позволить им работать с постоянным операционным управлением и соответствием стандартам — как внутри облаков, так и между ними. Ну а сегодня поговорим о новой версии решения Tanzu Application Platform 1.6 (в последний раз мы писали о нем тут).

Напомним, что на базе этой платформы, разработчики и операторы команд DevOps кластеров Kubernetes могут разрабатывать различные решения для Azure Kubernetes Service, Amazon Elastic Kubernetes Service, Google Kubernetes Engine, а также непосредственно для инфраструктуры на базе Tanzu Kubernetes Grid.

Основная идея Tanzu Application Platform - дать разработчикам средства для интеграции существующих и новых приложений в бэкенд инфраструктуру контейнеров с соблюдений требований комплаенса и безопасности. При этом сама платформа модульная - то есть разработчики могут выбирать утилиты, которые они используют.

Давайте посмотрим на новые возможности Tanzu Application Platform 1.6:

1. VMware Tanzu Developer Portal

Tanzu Developer Portal - это внутренний портал для разработчиков, созданный на базе Backstage. Он упрощает координацию, сотрудничество и выполнение задач в крупных организациях, разрабатывающих внутреннее программное обеспечение, между различными командами и бизнес-подразделениями. Портал разработчиков Tanzu служит интерфейсом для платформы Tanzu Application с момента ее первого релиза и теперь включает в себя инструмент конфигурации портала (в настоящее время в бета-версии) и поддержку интеграции плагинов (пока также в бета-версии).

2. Компиляция Spring Framework 6 в нативном режиме

Нативные образы Spring имеют ряд преимуществ по сравнению с традиционными приложениями на базе Java Virtual Machine:

• Улучшенное время запуска, особенно для приложений scale-to-zero.
• Меньшее потребление ресурсов, что позволяет организациям запускать больше приложений с тем же вычислительным ресурсом, сокращая общие затраты на инфраструктуру.
• Используя инструменты платформы Tanzu Application, разработчики могут создавать свои приложения Spring с нативной компиляцией при развертывании в продакшене, продолжая в реальном времени обновлять и удаленно отлаживать свои приложения в ненативном режиме, в своих интегрированных средах разработки (IDE).
• Разработчики могут просматривать онлайн-информацию о нативно скомпилированных приложениях Spring через Application Live View для VMware Tanzu и проводить быстрое устранение неполадок, проверяя состояние работающих процессов, изменяя уровни журналирования, обновляя свойства окружения и мониторя HTTP запросы/ответы.

Так выглядит Application Live View:

А вот так - детали приложения:

3. Автоматизированная конфигурация AppSSO для рабочих нагрузок приложений

Платформа Tanzu Application 1.6 упрощает процесс обеспечения безопасности рабочих нагрузок разработчиками с помощью AppSSO в различных окружениях, сохраняя их переносимость между средами. Разработчикам больше не нужно учитывать перенаправление URI для каждой среды при обеспечении безопасности своих приложений. Теперь они могут создать один ClassClaim, и рабочая нагрузка может быть развернута в нескольких средах без необходимости отдельных конфигураций для включения SSO в каждой среде. Это упрощение использования AppSSO позволяет разработчикам и инженерам платформы сосредоточиться на других параметрах для обеспечения безопасности рабочих нагрузок.

4. Создание проекта с использованием App Accelerators в IntelliJ

Разработчики могут начать новый проект за несколько минут из своей предпочтительной IDE. Теперь они могут предоставить репозиторий Git при создании проекта с использованием ускорителей в среде разработки IntelliJ IDE, и сгенерированный код отправляется в предоставленный репозиторий, что исключает необходимость ручного создания репозитория Git. Когда проекты создаются с использованием ускорителя из IntelliJ IDE, генерируется bootstrapping provenance manifest для приложения, чтобы предоставить ранний доступ внутри организации и дать возможность оценить, соответствуют ли приложения их лучшим практикам.

5. Улучшенное расширение для Visual Studio

Панель Workload в Visual Studio теперь показывает статус развернутой рабочей нагрузки, что позволяет разработчикам .NET управлять процессом работы с ошибками и решать проблемы.

6. Улучшенное взаимодействие с реестром образов контейнеров с помощью Local Source Proxy

Local Source Proxy предоставляет более безопасный и удобный для пользователя механизм, позволяющий разработчикам взаимодействовать с внешними реестрами без знания особенностей реестра, таких как эндпоинты, учетные данные и сертификаты.

Разработчики могут сосредоточиться на логике своего приложения, а не на управлении деталями реестра контейнеров в процессе разработки, что уменьшает сложность и ускоряет разработку. К некоторым преимуществам Local Source Proxy относятся:

• Возможность разработчиков развертывать рабочую нагрузку из локального исходного кода любым способом, включая расширения IDE, без указания местоположения исходного изображения или управления учетными данными реестра.
• Разработчикам больше не требуется устанавливать Docker на свои локальные машины для итерационной разработки.
• Local Source Proxy совместим с AWS ECR, включая предоставление роли AWS IAM для аутентификации ECR.
• Уменьшена нагрузка на команды платформы и операций по поддержанию, обновлению и распределению учетных данных реестра на рабочие станции отдельных разработчиков.
• Поведение по умолчанию для плагинов IDE платформы Tanzu Application, App Accelerators и CLI приложений было изменено в соответствии с функциональностью Local Source Proxy.

7. Доступность плагинов IDE на маркетплейсе в VS Code и IntelliJ

Разработчики обычно устанавливают расширения IDE из маркетплейса. Начиная с этого релиза, инструменты разработчика VMware Tanzu для VS Code и ускоритель приложений VMware Tanzu для VS Code будут доступны в маркетплейсе VS Code. Точно так же инструменты разработчика VMware Tanzu для IntelliJ будут доступны в маркетплейсе IntelliJ. Разработчики могут устанавливать расширение в своих IDE, что потенциально является более привычным процессом.

8. Безопасные по умолчанию рабочие нагрузки сервера

Разработчики теперь могут создавать рабочие нагрузки сервера, которые внешне доступны через интернет посредством Contour Ingress, и весь внешний HTTP-трафик защищен по умолчанию с помощью TLS. HTTPS через TLS автоматически настраивается для рабочих нагрузок сервера, без необходимости ручной настройки разработчиками.

9. Используйте свой предпочитаемый сканер (бета-версия)

Упрощение процесса интеграции сканеров уязвимостей образов контейнеров в цепочках доставки ПО стало ключевым улучшением релиза Tanzu Application Platform 1.6. Впервые представленный как альфа-версия в релизе Tanzu Application Platform 1.5, компонент Supply Chain Security Tools - Scan 2.0 теперь переведен в бета-версию.

Улучшения в этом релизе направлены на использование кастомных интеграций сканеров в Tanzu Application Platform, включая:

• Возможность включения компонента сканирования образов нового поколения в стандартную цепочку тестирования и сканирования.
• Результаты сканирования теперь отслеживаются и отправляются в хранилище метаданных для долгосрочного архивирования и извлечения.
• Результаты сканирования теперь представлены в Tanzu Developer Portal, включая Supply Chain Choreographer для VMware Tanzu и графические плагины для анализа безопасности.

10. Сортировка CVE с помощью Tanzu Insight CLI (альфа-версия)

Вы можете уменьшить использование таблиц и инструментов, централизовав сканирование, идентификацию и сортировку CVE в одном месте. Используя Tanzu Insight CLI, клиенты теперь могут выполнять основные функции сортировки по обнаруженным уязвимостям: просматривать, обновлять и клонировать статусы сортировки для конкретного CVE для рабочих нагрузок, просканированных на платформе Tanzu Application.

11. Отслеживание SBOM после каждой сборки

Теперь можно извлечь спецификацию программного обеспечения (SBOM) для определенной сборки рабочей нагрузки. Ранее клиенты могли генерировать SBOM только для последней сборки рабочей нагрузки. Через эндпоинты Metadata Store API клиенты могут загрузить SBOM из любой сборки рабочей нагрузки, что позволяет им лучше отслеживать изменения рабочей нагрузки для более быстрой проверки и устранения уязвимостей безопасности.

12. Загрузка SBOM прямо из Tanzu Developer Portal

Пользователи теперь могут загружать SBOM в форматах CycloneDX и SPDX прямо из Tanzu Developer Portal (в цепочке доставки Tanzu Developer Portal, этап сканирования образа). SBOM генерируется хранилищем метаданных и представляет собой актуальный SBOM. Эта возможность позволяет быстрее устранять уязвимости и обеспечивать соответствие стандартам.

13. Управление доступом к App Live View для чувствительных действий

Организации могут настроить более детализированное управление доступом для выполнения чувствительных действий, таких как изменение уровней журнала, изменение свойств среды и создание дампа памяти из работающих нагрузок для каждого пользователя, группы или на уровне рабочей нагрузки, предоставляя более тонкий контроль доступа к чувствительным действиям, особенно в производственных средах.

14. Экономьте время с автоматизированными сборками

Способность платформы Tanzu Application автоматически создавать сборки на основе изменений в верхних потоках зависимостей, используемых рабочими нагрузками, может улучшить безопасность и сэкономить время разработчиков. Этот функционал предоставляется службой VMware Tanzu Build Service. Использование Tanzu Build Service в цепочке доставки может дополнительно автоматизировать процесс, позволяя сборкам, созданным службой Tanzu Build Service, быть бесшовно развернутыми.

15. Плагин Build Service для VMware Tanzu CLI

Эта автоматизация цепочки доставки полезна, но разработчики и инженеры платформы могут захотеть углубиться в Tanzu Build Service. Разработчику может понадобиться доступ к дополнительной информации для диагностики неудачной сборки, или инженер платформы может захотеть изучить больше деталей о пакетах сборки, настроенных в цепочке доставки, или о конфигурациях, используемых при сборке рабочей нагрузки. Новый плагин Build Service для VMware Tanzu CLI помогает пользователям исследовать Tanzu Build Service, когда они хотят углубиться в слои абстракции цепочки доставки и лучше понять, как работает этот критически важный элемент.

16. Дополнительная поддержка самоподписанных CA

Платформа Tanzu Application теперь реализует поддержку Custom CA для внутренних репозиториев Git в цепочках доставки. Это особенно важная функция для клиентов в изолированных средах, так как они используют внутренние репозитории Git и свои пользовательские сертификаты.

17. Улучшения в Carvel Package Supply Chain

Цепочки поставок Carvel Package теперь поддерживают веб, серверные и рабочие нагрузки (бета). Эта функция позволяет пользователям Tanzu Application Platform создавать артефакт приложения (Carvel Package) с любым типом рабочей нагрузки Tanzu Application Platform, который можно перенести из одной среды в другую.

Клиенты также могут определять пользовательские параметры Carvel Package при использовании Carvel Package Supply Chain (бета), что позволяет им определять пользовательскую конфигурацию рабочих нагрузок для каждой среды. Это дает пользователям гибкость развертывания одного артефакта рабочей нагрузки с различными конфигурациями в реальном времени, которые обычно различаются между разработкой, тестированием, стейджингом или продакшн-средами.

18. Улучшенное журналирование ошибок, предоставляемое пакетами сборки

Клиенты Tanzu Application Platform теперь могут видеть улучшенное журналирование ошибок во время сборки. Теперь все сборки показывают команды и флаги, которые были введены в сборку, и поток вывода в реальном времени.

На этапе обнаружения сборки клиенты теперь могут видеть четкие детали о причинах сбоя сборки на этом этапе.

19. Установка через разные облачные платформы с улучшенным и упрощенным опытом установки

Теперь платформу Tanzu Application можно запустить с помощью установки на основе GitOps, которая устраняет необходимость вручную запускать несколько команд, сокращает сложность и экономит время. Методология GitOps включает в себя объявление желаемого состояния системы (обычно в Git) и процесс согласования, который направляет реальную систему (например, содержимое кластера Kubernetes) к сближению с желаемым состоянием (в Kubernetes, обычно сделанное через контроллер).

Процессы по установке GitOps были дополнительно улучшены интеграцией с внешними операторами секретов HashiCorp Vault, а также поддержкой Azure DevOps (репозитории). Клиенты, устанавливающие платформу Tanzu Application, теперь могут вносить изменения в свою систему, меняя желаемое состояние, сохраненное в репозитории Git. Это может значительно упростить процесс установки с использованием существующих инструментов клиента. Это также помогает клиентам проводить аудит и отслеживание изменений в их среде.

Решение VMware Tanzu Application Platform 1.6 уже сейчас доступно для пользователей.

Продолжаем рассказывать об анонсах новых продуктов и технологий, которые были сделаны на проходящей сейчас конференции VMware Explore 2023 в Лас-Вегасе, которая многие годы является главным событием в сфере виртуализации.

VMware Tanzu Application Engine предназначен для введения уровня абстракции, ориентированного на приложения, чтобы позволить им работать с постоянным операционным управлением и соответствием стандартам — как внутри облаков, так и между ними. Модель абстракции создает четкое разделение обязанностей между заинтересованными сторонами: разработчики смогут сосредоточиться на своих приложениях, не беспокоясь о деталях инфраструктуры, инженеры платформ смогут сосредоточиться на управлении и эксплуатации инфраструктуры в разных масштабах, а операторы смогут определять конфигурации для соответствия требованиям управления и стандартам организации.

Tanzu Application Engine ставит своей целью решение важных проблем для каждого из заинтересованных лиц, участвующих в выводе современных приложений в продакшен — в командах по приложениям, платформе и операциям.

• Разработчикам приложений предоставляется возможность самообслуживания для доступа к утвержденным средам приложений, называемым VMware Tanzu Application Spaces, что уменьшает когнитивную нагрузку, связанную с операциями в инфраструктуре, и ускоряет процесс релиза продуктов. Tanzu Application Engine также ставит своей целью позволить разработчикам приложений управлять и масштабировать свои приложения, даже когда инженеры платформы обновляют и поддерживают основные кластеры Kubernetes и связанную с ними инфраструктуру и ресурсы, предоставляя обеим командам пространство для работы и оптимизации приложений.
• Инженерам платформы могут пригодиться стандартизация и автоматизация полного цикла, позволяющая формировать и управлять средами приложений и основной инфраструктурой. Tanzu Application Engine разработан, чтобы позволить инженерам платформы повторно использовать, обновлять и управлять библиотекой профилей Tanzu Application Space, где находятся сформированные среды приложений, которые соответствуют текущим и будущим потребностям в области безопасности, производительности и стоимости содержания. Другие цели включают в себя возможности создавать резервные копии и восстанавливать Tanzu Application Space, а также обеспечивать бесперебойные обновления кластера.
• Операторы инфраструктуры (например, NetSec и операторы сервисов) могут определять необходимые конфигурации для достижения максимальной управляемости и соответствия стандартам для приложений, работающих в цикле Dev-Test-Stage-Prod и различных облачных вариантах использования. Автоматизированные API самообслуживания позволяют организациям смещать безопасность влево, не возлагая всю нагрузку на разработчиков. Например, оператор безопасности может определить конфигурации и политики, связанные с защитой данных для соответствия стандартам PCI DSS, в то время как оператор может формировать классы сервисов, облегчающие разработчикам приложений или операторам приложений запрашивать и байндить экземпляры сервисов, такие как базы данных, очереди сообщений и кэши для повышения производительности разработчиков.

С помощью Tanzu Application Engine компания VMware внедряет следующие основные принципы и технические нововведения:

• Внимание к опыту разработчика – Tanzu Application Engine предназначен для того, чтобы стать ключевой функцией платформы Tanzu Application, усиливая фокус VMware на упрощении опыта разработчиков в рамках полного цикла и позволяя разработчикам полностью сосредоточиться на написании кода и создании приложений.
• Баланс между простотой, гибкостью и вариативностью – простота для разработчиков быстро выводить свои приложения в продакшен, готовые или настраиваемые профили Tanzu Application Space - для операторов, и гибкость для команд платформы и эксплуатации, позволяющая выбирать из огромной экосистемы Kubernetes и дополнительных ресурсов VMware, необходимых для выполнения сложных требований приложения.
• Абстракции и сервисы, ориентированные на приложения – Tanzu Application Engine стремится предоставить уникальные абстракции и сервисы, которые находятся между приложениями и инфраструктурой, разделяя обязанности разработчиков приложений и операторов, и позволяя приложениям работать с постоянными возможностями и политиками — в кластерах и облаках.
• Модель сотрудничества с минимальными препятствиями – Tanzu Application Engine стремится представить модель сотрудничества с минимальным "трением", которая позволяет различным группам заинтересованных сторон, таким как инженеры платформы, NetSec и операторы служб, работать параллельно и самостоятельно вносить конфигурации в Tanzu Application Space, уменьшая неэффективность процессов, связанных с организационными единицами и ручными процессами.
• Готовые к использованию возможности – Tanzu Application Platform стремится предоставить богатый каталог возможностей, приложений и услуг, которые можно использовать с приложениями, работающими в Tanzu Application Spaces, как с открытым исходным кодом, так и проприетарным от VMware. Это позволит инженерам платформы выбирать из огромного экосистемного набора вариантов и легче внедрять стандарты безопасности, производительности и стоимости в пространства приложений.

Этот инновационный подход представляет собой будущее облачных платформ нового поколения в корпоративных публичных облаках и может решить технические и социальные проблемы функционирования в масштабе.

Больше о решении Tanzu Application Engine можно узнать из следующих сессий проходящей сейчас конференции VMware Explore 2023:

• MAPK2762LV – Solution Keynote: Accelerate Application Delivery for Continuous Innovation
• MAPB2682LV – VMware Tanzu: Your Complete Application Kubernetes Platform
• MAPB2711LV – See it Now: Integrated, End-to-End Application Delivery with VMware Tanzu
• MAPB2781LV – Accelerate App Delivery and Centralized Management on Public Clouds

На днях на сайте virten.net появилась информация об уязвимости CVE-2022-40982 Gather Data Sampling (GDS/Downfall) хостов VMware ESXi 8 инфраструктуры vSphere, которая может быть полезна для администраторов.

8 августа этого года компания Intel рассказала о проблеме "transient execution side-channel vulnerability" (уязвимость побочного канала при переходном выполнении), которая затрагивает определенные процессоры. В особых микроархитектурных состояниях CPU возможно раскрытие информации после transient-исполнения команд в некоторых векторных модулях исполнения, что может привести к ситуации, когда аутентифицированный пользователь может получить неавторизованный доступ к информации через механику локального доступа. Подробнее об уязвимости CVE-2022-40982 можно почитать тут.

Также вам могут быть полезны следующие ресурсы:

• Описание уязвимости Intel Security Advisory - INTEL-SA-00828
• Таблица CPU, которые затронуты
• Заявление VMware по этому поводу
• Информация от HP
• Информация от Dell

Чтобы понять, имеет ли ваш процессор данную дыру в безопасности, вам нужно получить о нем следующую информацию: CPU Family, Model и Stepping. Сделать это можно через PowerShell с помощью скрипта Get-CPUid, который вы можете скачать здесь.

Если вы посмотрели на вывод колонок и узнали там свой процессор из таблицы, а в колонке на сайте Intel увидели значение "MCU", то вам нужно накатывать обновление микрокода вашего сервера для защиты от угроз данного типа. Для получения обновления вам нужно связаться с вендором вашего серверного оборудования (например, ссылки для HP и Dell приведены выше).